home *** CD-ROM | disk | FTP | other *** search
/ SPACE 2 / SPACE - Library 2 - Volume 1.iso / music / 87 / c / numview.doc < prev    next >
Text File  |  1986-12-19  |  4KB  |  62 lines
  1.          BARS.C
  2.          BARS.TOS
  3.          NUMVIEW.C
  4.          NUMVIEW.TOS
  5.  
  6.                       Have you ever wondered what happened to all
  7.          those numbers that disappear from your figure tips and into
  8.          the ST's memory?  Here's your chance to look at some.
  9.          Numview allows you to enter an integer and then puts that
  10.          value into the 16,000 words (32,000 bytes) of memory that are
  11.          used for the screen display. Each word is 16 bits (a bit is
  12.          either one or zero).  In high resolution each pixel (short
  13.          for 'picture element') is set by a single bit (640X400 pixels
  14.          = 16,000 words X 16 bits/word = 32,000 bytes X 8 bits/byte).
  15.          If the value of the bit is one you see a black spot and, of
  16.          course, you see a white spot if the bit is zero.  Each row in
  17.          high resolution is 40 words (80 bytes).  In medium resolution
  18.          the screen memory is the same size, so how do we cram color
  19.          information into the same space?  The pixels are made larger
  20.          in medium resolution so that we have a screen resolution of
  21.          640X200 pixels.  To find which of the four colors (white,
  22.          black, red, green) a pixel has, the hardware looks for 2 bits
  23.          of information.  These two bits are found in two consecutive
  24.          words of screen memory.  As an example, let us consider the
  25.          very first pixel at the top, left hand side of the medium
  26.          resolution screen. The ST looks at the first bit of the first
  27.          word in screen memory and the first bit of the second word in
  28.          screen memory to determine this pixel's color value.  There
  29.          are 4 possibilities for the values of these two bits: 0 in
  30.          the first word and 0 in the second word ( we will call this
  31.          0,0); 0,1; 1,0; and finally 1,1.  Since Numview puts the same
  32.          number in each word of memory, we will see only 0,0 and 1,1
  33.          combinations.  It turns out this is normally displayed as
  34.          white and black in medium resolution.  Similar things happen
  35.          in low resolution (320X200 pixels), but now the ST looks at
  36.          four consecutive words in screen memory.  Thus, the first
  37.          pixel can have 16 color values depending on the first bit
  38.          values of the first 4 words in memory.  Once again, Numview
  39.          will show only 0,0,0,0 or 1,1,1,1 since all the words in
  40.          memory are the same.  And you guessed it, this is normally
  41.          shown as black and white even in low resolution.
  42.  
  43.              Try some integer values and you will see them converted
  44.          to binary and displayed as stripes on the ST screen.
  45.          Negative numbers are also interesting, try -1!
  46.  
  47.               Bars.tos displays 31 different screens sequentially each
  48.          with a different integer put in all of screen memory.  This
  49.          shows the speed of the ST's memory writing.
  50.  
  51.               Source code for both programs is included for those like
  52.          myself who are learning C.  I am currently using the Alcyon
  53.          package.  Numview.c shows a work around for the scanf()
  54.          function of the Alcyon package.  It seems that this function
  55.          requires a space to terminate any input to scanf().  This is
  56.          hardly standard user-interface friendliness!  I have made my
  57.          own input routine using Cconrs() and sscanf() so that the
  58.          carriage return can be used to terminate user input.  I am
  59.          sure there is a more concise way to transfer the input buffer
  60.          to a buffer usable by sscanf() (such as buffer = &input[2]
  61.          maybe), but this is what I got to work first.
  62.